Add skill to triage jira issues against code#108
Conversation
🤖 Bitwarden Claude Code ReviewOverall Assessment: APPROVE Reviewed the addition of the Code Review DetailsNo blocking or actionable findings. Notes considered and deliberately not flagged:
|
|
Howdy @ariane-bitwarden 👋🏼 Great start to the new skill, like 98% of the way there. Will you please update the Thanks! |
theMickster
left a comment
There was a problem hiding this comment.
Minor change to the frontmatter of the skill.
Item for discussion / follow-up changes
One thing to keep an eye on is the location where a user starts a session is important. The skill reads to me that the human should start a Claude session in the working directory above clients, server, etc. but what happens if you start a session or trigger the skill from inside clients?
| --- | ||
| name: triaging-jira-issues | ||
| description: Use when the user provides a single Jira issue key and asks whether it is still relevant, still applicable, still pending, still a bug, has been fixed, or can be closed. Trigger phrases include "Is [TICKET] still relevant?", "Is this still an issue?", "Is PM-123 still pending?", "Has this been fixed?", "Can we close this?", "Is this ticket still valid?", "Is this still applicable?", "Does this bug still exist?". Fetches the ticket and verifies the described problem against the current codebase to return a verdict with evidence. This skill triages a single ticket at a time; invoke it iteratively for multiple tickets. | ||
| --- |
There was a problem hiding this comment.
allowed-tools frontmatter property.
| --- | |
| allowed-tools: Bash(git log *) Bash(git show *) Grep Read | |
| --- |
There was a problem hiding this comment.
Updated allowed-tools to include referenced commands and tools.
| - **The specific problem or task**: Read beyond the summary. The description, acceptance criteria, and replication steps are more precise. For bugs: what is the actual broken behavior and what is expected? For tasks: what specific code change is required? | ||
| - **Technical identifiers**: Method names, class names, file paths, API endpoint routes, UI strings that appear in source, config keys, feature flag names — anything named in the ticket that can be searched in code. Note these explicitly before moving on. | ||
| - **Filed date**: Used to scope `git log` searches. | ||
| - **Repo scope signal**: Determine whether this applies to `clients`, `server`, `sdk-internal`, or a combination. Use the team field, component labels, and description content (see Scope Notes below). |
There was a problem hiding this comment.
❓Is this skill intentionally limited to these specific repositories?
There was a problem hiding this comment.
Removed hardcoded repos and mappings so that Claude does not silently ignore relevant repos that are not listed. Claude will make a best-effort attempt to infer the relevant repo(s) then ask the user for confirmation. This eliminates the potential for error in identifying relevant repos.
|
|
||
| ## Workflow | ||
|
|
||
| ### Step 1: Fetch the Ticket and Its Context |
There was a problem hiding this comment.
@ariane-bitwarden should we consider also fetching the Github issue if it's linked to one via the "Github URL" field, and doing the same staleness checks there? If users are reporting it as still happening in Github then that's a signal.
There was a problem hiding this comment.
@trmartin4 I like the idea, but I think it goes beyond the intended scope of this PR. I'd like to defer that to a follow-up addition.
…SKILL.md Removing reference to a bulk skill that does not exist yet. Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
The skill was limited to clients, server, and sdk-internal via a hardcoded Scope Notes mapping, so tickets against any other Bitwarden repo were misrouted. It also assumed affected repos were cloned locally without checking; searching an absent repo returns no matches, which reads the same as the code having been deleted and could close a live ticket. Repo scope is now confirmed with the user before any searching, and the skill halts without a verdict when a repo in scope is unavailable. Renamed because the skill does not triage: it assesses one ticket at a time and neither ranks nor prioritizes across a set. Adds scoped allowed-tools so routine use stops prompting on every MCP fetch. No version bump: 2.4.0 is unpublished and exists only on this branch, so the changelog entry was folded in rather than superseded.
865090b to
8d03837
Compare
Plugin Validation Summary — PR #108Plugin: This PR adds one new skill, Changed files reviewed
1. Plugin Structure Validation — ✅ PASS
2. Skill Review — ✅ PASS
Strengths noted: strong safety design (Step 2 hard-halt when a repo is not cloned, with rationale for why proceeding would yield a false "No longer relevant"); clear separation between the Step 2 halt and the Step 5 "Cannot determine" verdict; least-privilege Minor / optional (warnings, non-blocking):
3. Security Validation — ✅ PASS
Overall Assessment✅ Ready to merge. Clean MINOR version bump adding one well-structured, correctly-scoped skill. Version, manifest, marketplace entry, and changelog are mutually consistent; frontmatter and file references valid; least-privilege permissions; no credentials leaked. Only two optional, non-blocking polish suggestions on the skill. Note: the repo scripts |

🎟️ Tracking
N/A. Adds the
assessing-jira-issue-relevanceskill tobitwarden-atlassian-tools.📔 Objective
Adds a skill that assesses whether a Jira ticket is still relevant or has been addressed.
It gathers ticket context, determines repo scope, identifies and searches for relevant code (locally), and delivers a verdict on the ticket's relevance.
If the skill cannot locate in-scope repos on disk, it will prompt the user to either clone the repo or point to where it is already cloned. Should the user reject, the skill aborts to prevent partial analysis.